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1.0 Introduction 



1.1 Revision History 



Version 


Changes 


0.80 


Original version. 


0.81 


Grammatical corrections. 


1.00 


Finalized for public release. 


1.01 


Added the BiosSelector parameter to the run-time functions. 

Moved run- time functions 65h and 66h from Appendix C to Appendix B. 

Cleaned up documentation on the run-time functions. 



You may obtain the latest copy of the BIOS Boot Specification from the Phoenix 
world wide web site at http://www.ptltd.com, or by contacting a representative from 
one of the authoring companies. 



Technical Editor: 

Scott Townsend 

Phoenix Technologies Ltd. 

2575 McCabe Way 

Irvine, CA 92714 

Phone: (714) 440-8000 

Fax: (714)440-8300 

Email: Scott_Townsend@ptltd.com 



1.2 Related Documents 



Title 


Version 


Author 


Plug and Play BIOS Specification 


1.0A 


Compaq/Phoenix/Intel 


Hardware Design Guide for Microsoft Windows 95 


L0 


Microsoft Corporation 


Enhanced Disk Drive Specification 


LI 


Phoenix 


"El Torito" Bootable CD-ROM Format 
Specification 


1.0 


Phoenix/IBM 


PCI Local Bus Specification 


2.1 


PCI Special Interest Group 



1-3 Purpose 

The purpose of this specification is to describe a methodology by which the BIOS will 
identify all IPL (Initial Program Load) devices in the system, prioritize them in the 
order the user selects, and then sequentially go through each device and attempt to 
boot. The BIOS must become more intelligent about booting because the Plug and 
Play BIOS Specification places additional requirements on the BIOS during the boot 
process, and there are now more devices that are bootable such as CD-ROM, network 
remote boot, PCMCIA, etc. It is important that this specification define a boot scheme 
that is generic and flexible enough to allow booting from virtually any existing IPL 
device, and for the definition of future IPL devices as well. 
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1.4 Terms 



To avoid confusion and to be consistent with the Plug and Play BIOS Specification, 
definitions of some of the terminology used in this document are listed below. 

ATA 

An Advanced Technology Attachment drive, also known as an IDE drive, is a hard 
drive with the interface built-in. 

ASCIIZ 

An ASCIIZ string is simply a string of ASCII characters terminated by a NULL (0 
byte). 

BAID 

A BIOS Aware IPL Device is any device that can boot an O/S, but requires the BIOS 
to have specific code to support it. Some examples are: the first floppy drive, the first 
hard drive, ATAPI CD-ROM, PCMCIA, embedded network adapter, etc. 

BCV 

A Boot Connection Vector is a pointer that points to code inside the option ROM that 
will perform device initialization, detect if a peripheral (such as a SCSI hard drive) is 
attached, and optionally hook INT 13h. The BCV resides in a PnP option ROM 
Expansion Header. An example of an option ROM with a BCV is a PnP ISA SCSI 
controller. 

BDA 

The BIOS Data Area is a data storage area in RAM. The BDA is used by the BIOS to 
manage the various peripherals and resources in the system. The BDA starts at 
segment address 0040h. 

BEV 

A Bootstrap Entry Vector is a pointer that points to code inside an option ROM that 
will directly load an O/S. The BEV resides in a PnP option ROM Expansion Header. 
An example of an option ROM with a BEV is a PnP ISA ethernet controller. 

BIOS 

The Basic Input/Output System is the software embedded on a chip located on the 
computer's main board. The BIOS executes POST to test and initialize the system 
components and then loads (boots) the O/S. The BIOS also handles the low-level 
input/output to the various peripheral devices connected to the computer. 
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Boot Device 

A Boot Device is any device that must be initialized prior to loading the O/S. This 
includes the primary input device (keyboard), the primary output device (display), and 
the initial program load device (floppy drive, hard drive, etc.). An IPL device is one 
form of a boot device. 

CDR 

Conflict Detection and Resolution is a method by which a PnP BIOS first detects the 
resource requirements for PnP cards, and then allocates them in a conflict-free way. 

CSN 

A Card Select Number is a number that uniquely identifies a PnP ISA card and is used 
to communicate exclusively to that card. The CSN is assigned by the PnP BIOS to 
each PnP ISA card in the system. 

DDIM 

The Device Driver Initialization Model is a method of initializing an option ROM 
whereby the option ROM is first copied to shadow RAM, then its initialization vector 
is called with the shadow RAM write-enabled. When the option ROM completes 
initialization it may dispose of code not needed at run-time by re-sizing the ROM 
memory footprint. Finally, after the option ROM returns and the BIOS regains 
control, the ROM is write-protected. 

DV 

A Disconnect Vector is a pointer that points to code inside the option ROM that will 
perform clean-up after the Boot Connection Vector has already been called. The DV 
resides in a PnP option ROM Expansion Header. An example of an option ROM with 
a DV is a PnP ISA SCSI controller. 

IPL Device 

An Initial Program Load Device is any device in the system that can boot and load an 
O/S. In standard AT machines, this is the floppy drive or hard drive. 

Legacy Card 

A Legacy Card is a standard ISA card that contains no PnP compatible configurability, 
and no PnP Expansion Header. 

NV 

Non-Volatile memory is memory that is retained even when the power has been shut 
off. The most common type of NV memory on a PC is the CMOS RAM that is used 
to store system configuration information. 

O/S 

An Operating System is loaded from an IPL device when that device is selected for 
booting. 
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PFA 

A PCI Function Address is a unique number assigned to a PCI function on a PCI 
device. The PFA consists of a function number, a device number, and a bus number. 

PnP 

Plug and Play is a term used to identify anything defined by the Plug and Play BIOS 
specification or the Plug and Play ISA specification. The term will typically be used 
to reference some device or behavior that is specific to PnP technology. 

PnP Cards 

PnP Cards consist of any cards that contain an option ROM with a PnP Expansion 
Header. 

POST 

The Power-On Self Test is the part of the BIOS that takes control immediately after the 
computer is turned on. POST initializes the computer hardware so that an O/S can be 
loaded. 

Setup 

The system Setup program is the part of the BIOS that is executed after a user 
specified <Hot Key> is pressed during the BIOS initialization. Setup allows the user 
to set up and configure the system as well as select the IPL Priority of the system. 
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2.0 Overview 

2.1 Description 

The BIOS Boot Specification defines a feature within the BIOS that creates and 
maintains a list of all the IPL devices found in the system and stores this list in NV 
memory. IPL devices come in three flavors: BAID, PnP Card, and Legacy. Only 
BAIDs and PnP Cards are enumerated. Legacy devices are not supported for several 
reasons. First, they tend to take control of the boot process altogether making them 
rather unfriendly. Second, they provide no means for identifying themselves as an IPL 
device. Finally, the BIOS cannot selectively boot from one of several Legacy IPL 
devices in a system. 

The BIOS Boot Specification provides one basic feature, the IPL Priority. The IPL 
Priority is a user-specified priority of IPL devices that is arranged in Setup. This boot 
order is similar to the common feature of boot A: then C: or vice versa, but supports 
additional IPL devices. Also, the number of IPL devices in the system may vary from 
one power-on to another. Each time the user turns on the system all IPL devices in the 
system are enumerated. 

Additionally, the BIOS Boot Specification defines the BCV Priority. The BCV 
Priority is a user-specified priority list of INT 13h Device Controllers that is arranged 
in Setup. This list specifies the order that the controllers will be called to install their 
INT 13h drive support during POST. 

If an IPL device fails to load an O/S, the BIOS regains control and attempts to boot 
from the next available IPL device. This procedure will continue until all possible IPL 
devices have been exhausted. Only then will the BIOS display a message that an O/S 
cannot be found, wait for a key stroke, and then invoke INT 19h again. This method 
ensures that the BIOS has intelligently made every attempt to boot. 

The BIOS Boot Specification encompasses the boot process of both PnP and non-PnP 
systems. The support for PnP Cards wherever mentioned is only pertinent to systems 
which include PnP support in their BIOS. A standard AT compatible system (also 
called a Legacy system) is much simpler than one with a PnP BIOS because it only 
supports BAIDs. A Legacy system does not need to provide any dynamic IPL device 
enumeration or configuration, nor does it support PnP Cards in their native mode. 
This is because the number of IPL devices in such a system will never change. 
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3.0 IPL Devices 



3.1 Requirements for IPL Devices 

An IPL device can be virtually any device that has the ability to load and execute an 
O/S. This includes floppy drives, hard drives, CD-ROM drives, PCMCIA 
controllers/cards, PnP Cards, Legacy cards, and could, in the future, include virtually 
any devices such as serial ports, parallel ports, etc. An IPL device falls into one of 
three categories: BAID, Legacy IPL Device, or PnP Card. There are two varieties of 
PnP Cards, BCV devices and BEV devices. 

One of the key points of concern about an IPL device is that it be able to return back to 
the BIOS with an error if the O/S load fails. The BIOS Boot Specification defines INT 
18h as the recovery vector for failed boot attempts. For example, if a PnP ISA 
network card was configured to boot from the network, but the network cable wasn't 
attached, the card's option ROM should signal to the BIOS that it cannot boot by 
invoking INT 1 8h. 

If a Legacy card's option ROM code hooks INT 19h during its initialization call it 
controls the boot process. If a Legacy card hooks INT 18h, the boot failure recovery 
will not work. For this reason, it is recommended that all future Legacy boot devices 
include the PnP Eixpansion Header and its associated support in their option ROMs so 
that their priority in the booting process can be controlled. 

3.1.1 IPL Table 

Each BAID and BEV device must have corresponding entries in the IPL Table. An 
IPL Table for a typical PC would have two BAID entries, one for diskette drive A: and 
one for hard drive C:, and one for each BEV device found. A sample IPL Table is 
shown in section 4.1. 

The information stored in the IPL Table consists of identification information, pointers 
to description strings, and pointers to handlers that will initiate an O/S load. The IPL 
Table and BCV Table data structure is defined in detail in Appendix A. 



10 



3.1.2 Product Name String 



The Plug and Play BIOS Specification defines fields in the PnP Expansion Header for 
optional description strings. Vendors of PnP Cards must have meaningful strings in 
the Product Name String and Manufacturer String fields of the PnP Expansion Header. 
The Product Name String is particularly important since it will be displayed to the user 
as an identifier for that device. Although the only current limitation to these strings is 
that they be terminated by a NULL (0 byte), it is declared here that only the first 32 
characters (bytes) of the Product Name String are significant. Characters beyond 32 
will not be displayed. This is a reasonable length to provide the user with a unique 
name for that device. Product Name Strings shorter than 32 will be displayed in their 
entirety. 

3.2 BAIDs 

BAIDs include the first floppy drive, the first hard drive, and any other bootable 
device that has specific code in the BIOS to support it. A BAID is able to launch a 
bootstrap only because the BIOS has built-in support as part of the INT 19h service 
routine. Some examples of this might be an ATAPI compatible CD-ROM drive or a 
PCMCIA card/controller. BAIDs do not have option ROMs, nor can they function 
without specific code embedded in the BIOS. 

Each BAID will have an entry in the IPL Table. This entry will contain the following 
information: the device type, a device sub-type, a pointer to a description string, and a 
pointer to code that will attempt to boot from the device. The INT 19h handler will 
read this table and be able to boot from any one of these devices without having to 
know what type of device it is. The table consists of a contiguous array of data 
structures of which each corresponds to a particular IPL device. 

Note that only the first floppy drive and the first hard drive are considered IPL devices. 
The main reason why a system cannot boot from other drives is that the boot sector 
code specifically addresses only these drives (OOh for floppy and 80h for hard drive) 
when INT 13h is called to load the O/S. See Appendix D for recommended changes 
to the O/S boot sector that could solve this problem. 
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3.3 Devices with PnP Expansion Headers 

All IPL devices with option ROMs must contain a valid option ROM header that 
resides between system memory addresses COOOOh and EFFFFh on a 2k boundary and 
begins with 55AAh. A Device's booting can only be controlled if it has a PnP 
Expansion Header. The Expansion Header, whose address resides within the standard 
option ROM header at offset +1 Ah, contains important information used to configure 
the device. It also contains pointers to code in the device's option ROM (BCV or 
BEV) that the BIOS will call to boot from the device. See Appendix A for the 
structure of the PnP Expansion Header. There are two ways an IPL device with a PnP 
Expansion Header can be booted. It must contain a BCV or a BEV. 

A BEV device, typically a network card, is booted by the BIOS making a far call 
directly to its BEV. If the device fails to boot, it executes an INT 18h which returns 
control back to the BIOS. BEV devices behave much like BAIDs in that they are 
selectively bootable. 

A BCV device, typically a SCSI controller, is not directly bootable. Rather, it merely 
adds its drives to the system by hooking into the BIOS' INT 13h services and 
appending drive numbers to any existing drives. Since only drive 80h is bootable, a 
BCV would only be able to boot one of its drives if it installed before any other drives 
in the system. For this reason, it is necessary to control the order that all drives are 
installed into the system, including on-board ATA drives and those controlled by 
Legacy devices such as older SCSI controllers. The only way to control a BCV 
device's drives in the boot order is by allowing the user to specify the order of 
initialization among ATA, BCV, and Legacy option ROMs. This will be discussed in 
detail in section 5.0. 

3.4 Legacy IPL Devices 

This is a standard ISA card with a valid option ROM that resides in system memory 
address space between COOOOh and EFFFFh on a 2k boundary. An example of this 
type of device is a Legacy SCSI hard drive controller with a bootable ROM installed. 
Legacy IPL devices do not contain PnP Expansion Headers in their option ROMs. 

Option ROMs are detected during the BIOS' scan and their initialization vectors are 
called. During initialization, devices may hook INT 1 9h so that they will gain control 
when the BIOS issues INT 19h to boot the system. Or, they may hook INT 18h so that 
if all other IPL devices in the system fail to boot they will take over. Or, they may 
simply hook INT 13h and only respond to calls that reference their drive number. In 
any case, the first two methods provide no consistent way for the BIOS to regain 
control if the device fails to boot. 
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Legacy IPL devices will be allowed to take control of the system (via hooking 
interrupts) in both Legacy and PnP systems. The Plug and Play BIOS specification 
recommends that Legacy devices that hook a bootstrap interrupt such as INT 1 9h, 1 8h, 
or 13h have the interrupt re-captured by the BIOS. This is not done because grabbing 
an interrupt vector back after a device has hooked it can produce unpredictable results. 
Further, by allowing the card to take control, the behavior of these Legacy cards will 
be the same on both PnP and Legacy machines. 

Legacy IPL devices are not enumerated or handled in any special way. Their behavior 
will be largely unknown by the BIOS. If a Legacy IPL device traps INT 19h it takes 
control of the boot process. This is acceptable because it is consistent with what 
Legacy systems do now. If a Legacy IPL device traps INT 13h, it becomes the local 
hard drive from the BIOS' perspective since it would then respond to INT 13h 
function calls executed in the INT 1 9h handler. 
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3.5 Identifying IPL Devices 

The large variety of possible IPL devices dictates that a generic methodology be 
implemented so that all existing and future devices can be made bootable with a 
minimum of difficulty. All IPL devices in the system need to be enumerated during 
POST, but before INT 19h. All IPL devices fall into one of three categories: BAID, 
PnP Card, or Legacy. 



IPL Device 


Type 


First floppy drive 


BAID 


First ATA Hard drive 


BAID 


PCI ATA card w/ drive 


BAID 


ATAPI CD-ROM drive 


BAID 


PCMCIA controller w/ bootable card 


BAID 


Ethernet controller w/ code embedded in BIOS 


BAID 


PnP Token Ring card 


PnP (BEV) 


PnP ethernet card 


PnP (BEV) 


Non-PnP card w/ PnP Expansion Header 


PnP (BEV or 
BCV) 


PnP SCSI card w/ drive 


PnP (BCV) 



3.5.1 BAIDs 



All BAIDs are automatically identified because the BIOS has specific code to support 
them. In addition, each BAID has a corresponding entry in the IPL Table. 

3.5.2 PnP Expansion Header 

A PnP Card is defined by having a PnP Expansion Header in its option ROM. Any 
IPL device with an option ROM can contain the PnP Expansion Header, including PCI 
and ISA devices. If a PnP Expansion Header exists, the device will be treated as a 
PnP Card. If it is a BEV device it will be included in the IPL Priority. If it is a BCV 
device the BCV will be called. The PnP Expansion Header method of identifying boot 
devices with option ROMs is expected to become the future standard. 

3.5.3 PCI Devices 

From the standpoint of booting, most PCI IPL devices with option ROMs behave just 
like Legacy IPL devices. Currently, most PCI SCSI controllers will typically hook 
INT 13h and most PCI network cards typically hook either INT 19h or INT 18h in 
order to be an IPL device. It is recommended that all future PCI devices with option 
ROMs employ the PnP Expansion Header method for booting so that they may enjoy 
the benefits of appearing on a boot menu and allowing users to select its boot order. 
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PCI devices without option ROMs are either not an IPL device, or they behave like a 
BAID. For example, a PCI ATA controller will not have an option ROM, but will 
become the system ATA controller and utilize the BIOS' INT 13h services to interface 
to attached ATA drives. 

The address space for option ROMs conforming to the Device Driver Initialization 
Model (DDIM), such as PCI, shall be write-enabled both when their initialization 
vector is called, and when their BCV is called. 

3.5.4 Identical IPL Devices 

In an implementation of the BIOS Boot Specification, the system BIOS may choose to 
distinguish between identical IPL devices so that the user will be able to choose the 
correct device, given a menu of selections. For instance, the system BIOS may 
recognize that two identical PnP SCSI controllers are present in the system and 
distinguish them by numbering them, by displaying their CSN, or some other method. 
Currently, no specific method is recommended nor defined here. Recognizing and 
dealing with identical devices is optional and not required for BIOS Boot Specification 
compliance. 
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4.0 IPL Priority 



Once all BAIDs and BEV devices in the system have been identified and enumerated, 
the BIOS needs to decide in which order they will be selected for booting. This is 
handled by the IPL Priority. 

The IPL Priority consists of an array of ordinal values, one for each BAID and BEV 
device found in the system at POST. An IPL Priority ordinal value is the index of a 
BAID or BEV device entry in the IPL Table. The priority for IPL devices is 
configurable by the user by editing the IPL Priority in Setup. The order the user 
selects is then stored in NV memory so that it can be retrieved by the BIOS at INT 19h 
time. The IPL Priority specifies not only the number of BAIDs and BEV devices in 
the system, but their order of booting as well. 

When the INT 19h handler gains control, the first IPL device in the IPL Priority is 
used to attempt to boot. If that fails, the next device is tried, and so on until all devices 
in the IPL Priority have been tried. At that point an error message will be displayed 
since all attempts to boot have been exhausted. 

4.1 Maintaining the IPL Priority 

Since the ordinal values in the IPL Priority are simply the index of the IPL device in 
the IPL Table, no information is stored as to the specific IPL device that the ordinal 
value represents. Here we assume that the number of BAIDs in a system does not 
change because the BIOS contains the code for them. The BIOS recognizes only a 
change in the number of BEV devices, and not a change in the type of BEV devices. 

If the user changes the BEV devices they have in their system without changing the 
total number of BEV devices, the BIOS will not detect this and will keep the previous 
IPL Priority. For example, if there is a PnP ISA ethernet card in a system and the user 
removes it and installs a different PnP ISA ethernet card, the IPL Priority would not 
change because the BIOS does not track individual BEV devices. It merely tracks the 
number of them and their order in the IPL Priority. The IPL Table would contain an 
entry for the new PnP ethernet card in the same location as where the old one was 
before. Again, as long as the total number of BEV devices doesn't change, the BIOS 
uses the last order that was stored in NV memory. 
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The way the IPL Priority is constructed is by taking the range of ordinal values for 
BAIDs and BEV devices, and storing them in NV memory in the IPL Priority order. 
The maximum number of IPL devices supported is implementation specific, and is 
defined at BIOS build time. The number of BAIDs also does not change. The number 
of BEV devices that were detected at the last boot is stored in NV memory so that a 
change in this number can be recognized by the BIOS. If the number of BEVs found 
during POST differs from the number found at last boot as indicated by the value 
stored in NV memory, the BIOS should either reset the IPL Priority automatically to 
reflect the changes, or prompt the user to enter Setup. 

When the system boots for the first time, or if the NV memory is corrupted, a default 
IPL Priority is created. The default IPL Priority consists of the BAIDs followed by the 
BEV devices found in the system. The BEV devices are placed at the end of the IPL 
Priority in the order that they are found. Optionally, the user can be prompted to enter 
Setup. 

The IPL Priority remains in effect until either the user changes it or the number of 
BEV devices in the system changes. However, the IPL Priority could change in a 
system with more than one BEV device if the order the BEV devices were found by 
the PnP BIOS changed. This seems odd at first to have the IPL Priority change and 
the user not be notified. But ultimately, if the user is changing boot devices they will 
probably want to manually edit the IPL Priority anyway. This caveat saves a lot of 
potential consumption of NV memory that would be used to store unique serial 
numbers for each BEV device. Additionally, BIOS code space is saved by not 
tracking individual BEV devices as opposed to simply enumerating the existing ones 
without reference to what type of device they are. 





IPL Table 


0 


Floppy A: 


1 


Hard Drive C: 


2 


CD-ROM 


3 


BEV#1 


4 


BEV #2 


5 




6 




7 





IPL Priority 

012 3 4 5 6 7 

3 I 4 I 1 I 2 I 0 I I 



When INT 19h is executed, the BIOS will process the IPL Priority shown above in the 
following order: BEV #1, BEV #2, Hard Drive C:, CD-ROM, Floppy A:. 
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4.2 IPL Priority Pseudocode 

The following pseudocode describes an example of managing the IPL Priority during 
POST. 

Created at BIOS build time: 

• First few IPL Table entries are filled in by the BAIDs. 

• maxIPLCount = Number of entries in IPL Table. 

• baidCount = Number of BAIDs in the system. 

• maxBEVCount = (maxIPLCount - baidCount). 

• The NV memory space for the IPL Priority is reserved. 

Assumptions: 

• The default for the IPL Priority will automatically be created during POST in case 
the NV memory gets corrupted. 

• nvBEVCount = number of BEV devices found last time - stored in NV memory. 

• postBEVCount = number of BEV devices found this time. 

Execution at POST time: 

• All option ROMs with a PnP Expansion Header are identified and their 
initialization entry points are called. 

• Additional IPL Table entries are filled in with the BEV devices found. 

• IF (NV memory is corrupted) 

• Set default IPL Priority by first placing the BAIDs, and then adding in the 
BEVs in the order they were found. 

• ELSE 

• The IPL Priority is retrieved from NV memory. 

• deltaBEVCount = (nvBEVCount - postBEVCount). 

• IF (deltaBEVCount != 0) 

• IF (deltaBEVCount > 0) 

• FOR (i = 0; i != deltaBEVCount; ++i) 

• Add a new BEV device to the end of IPL Priority. 

• ELSE 

• For (i = 0; i != deltaBEVCount; »i) 

• Delete the BEV device nearest the end of IPL Priority. 

• ENDIF 

• Save the postBEVCount in NV memory as nvBEVCount. 

• Save the new IPL Priority in NV memory. 

• (Optional) - Display a message that the IPL Priority changed and 
allow the user to enter Setup to reconfigure the IPL Priority. 

• ENDIF 

• ENDIF 

• Invoke INT 19h. 
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5.0 BCV Priority 



5.1 Introduction 

In order to fully manipulate the order that IPL devices attempt to boot, it is necessary 
to control the order of installation of devices utilizing INT 13h. Since many INT 13h 
devices can be managed by one controller, we need to control the order that the 
controllers' INT 13h support is installed. The need to manage this ordering arises out 
of the currently limited booting capabilities of today's average PCs. Specifically, there 
is no standard way for the user to: 

1. boot from a Legacy or PnP SCSI controller's hard drive when there are also ATA 
drives present in the system. Typically the on-board ATA support resident in the 
BIOS is installed before the BIOS' option ROM scan, making it the first to install 
into the INT 13h services. This results in the bootable drive number 80h being 
allocated to an ATA drive, thus making drives whose support is installed later 81h 
or higher and therefore non-bootable. 

2. control the order that PnP BCV devices are installed into the INT 13h services. If 
there are several BCV devices in the system and each has a hard drive which 
contains a different O/S, there is no way to select booting from one device this time 
and a different device another time. Currently, the BCV devices are either installed 
randomly, or at best in the order in which they are found. 

5.2 INT 13h Device Controllers 

An INT 13h Device Controller installs one or more drives into the BIOS' INT 13h 
services by hooking the INT 13h software interrupt and chaining to the old vector. A 
controller can be in the form of the BIOS' own INT 13h services for ATA drives, a 
PnP Card with a BCV, or the collection of Legacy cards with option ROMs. 

All controllers must be able to install in any order. This means before or after the 
BIOS installs its ATA drive support, and before or after the Legacy option ROMs are 
called for initialization. 

5.2.1 ATA Drive Support in the BIOS 

The first type of entry in the BCV Table is the BIOS' own INT 13h services for ATA 
drives. The ATA drive support in the BIOS must be able to install after other 
controllers have installed. The BIOS cannot assume that the drives it installs will 
occupy the first drive numbers (80h, 81h, etc.). No attempt is made to enumerate or 
control the installation order of individual ATA devices, although nothing defined in 
this specification would prevent this from being accomplished. 
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5.2.2 PnP Cards with BCVs 

PnP Cards with BCVs are the second type of entry in the BCV Table. All PnP Cards 
will have their initialization vectors called before their BCV is called. Calling the 
BCV allows the PnP Card to install support for one or more drives into the INT 13h 
services. 

5.2.3 Legacy Cards with Option ROMs 

The third type of entry in the BCV Table is all Legacy cards with option ROMs. A 
Legacy card will install its INT 13h drive support when the BIOS calls the Legacy 
card's initialization vector. No attempt is made to enumerate or control the installation 
order of individual devices, although nothing defined in this specification prevents 
this. 

5.2.4 Hard Drive BAID 

The first INT 13h Device Controller that successfully installs support for drive 80h 
becomes the Hard Drive BAID, thus making it an IPL device and relating it to the IPL 
Priority. 

5.2.5 Controller Installation Guidelines 

• Each controller may install INT 13h support for one or more drives. 

• When INT 13h is hooked, the old vector will be saved. 

• A controller will only respond to requests which specify the drive number for 
which it has control, and will pass on requests to other drive numbers to the old 
vector. 

• A controller may not know if it has any drives attached until it is called to install. 
If no drives are attached, then the controller should not hook INT 13h. 

• The number of hard drives currently installed is stored in the BDA at address 
0040:0075. When a controller installs support for additional drives, this location 
must be incremented by the number of drives that are to be added. 

• A controller must install INT 13h support by using sequentially increasing drive 
numbers starting after the drives previously installed. For example, if two drives 
are already installed when the controller gets called, they will occupy drive 
numbers 80h and 81h. The next available numbers for the controller to occupy 
would be 82h, 83h, etc. 

• A controller checks if the location at 0040:0075 is zero to determine if it is the first 
to install. If it is first, the controller must copy the INT 13h vector over the INT 
40h vector so that floppy services are handled properly. 

• The first controller to install will get drive number 80h. The controller then knows 
that it controls the hard drive boot device. 
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• Once a controller has hooked into INT 13h services, it can never unhook, since 
controllers hooked in after it would be lost. 

• Any controllers such as Legacy cards which hook INT 18h or INT 19h may end up 
taking over the boot process and may possibly reduce the capability of the BIOS to 
control the boot order. 

5.2.6 Notes on INT 13h Devices 

• No assumptions can be made by the controller as to what types of devices are 
installed in the system. For instance, if a PnP ISA SCSI card's BCV is called to 
install, and support for other drives is already present, the BCV handler cannot 
assume that the existing drives are on-board ATA drives. 

• Neither controllers nor O/S's should make assumptions about how INT 13h drive 
numbers are assigned. The installation ordering of INT 13h Device Controllers 
allows controllers to install drivers in any order selected by the user. This could 
create compatibility problems with some O/S's that assume drive 80h is an ATA 
drive. The Enhanced Disk Drive (EDD) Specification describes a method by 
which an ATA drive's resources may be determined. 

• Drive numbers assigned to ATA and ATAPI drives for primary and secondary 
channels, as well as master and slave drives, are not guaranteed to be consecutive. 
The assignment of drive numbers is done by the INT 13h Device Controller when 
it installs its support. The controller may choose to assign drive numbers without 
regard to whether the drives are on a primary or secondary channel, or configured 
as master or slave. 

5.3 Installation Ordering 

The BIOS can control the order of installation of controllers of INT 13h devices if it 
maintains a priority list (similar to IPL Priority) and provides the user with the 
capability of editing the order and saving it in NV memory. The BIOS must then 
install the controllers in the order the user specified. The three types of controllers 
mentioned previously each install in different ways. Support for ATA drives is 
installed by executing internal BIOS code. PnP BCV devices require two calls, one to 
their option ROM which describes their capabilities to the BIOS, and then one to their 
BCV which allows them to hook into INT 13h. Finally, Legacy cards with option 
ROMs install entirely when their option ROM is called. So the BIOS must have the 
ability to dynamically control each of these events. 
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The installation ordering is very similar to the process used for managing the IPL 
Priority (BAIDs and BEV devices). A table of controllers called the BCV Table is 
built early in POST which includes all three types of controllers and pointers to code 
that can install them. A set of ordinal values called the BCV Priority is stored in NV 
memory and is used to index a particular controller in the BCV Table. The number of 
BCV devices is also stored in NV memory and is checked at each POST to see if a 
change occurred. If so, the BCV Priority is adjusted automatically by the BIOS. A 
sample BCV Priority is depicted below. 



BCV Table 

0 ATA Drives 

1 Legacy Cards 

2 BCV#1 

3 BCV #2 

4 

5 

6 

7 



BCV Priority 

012 3 4 5 6 7 

2 | 0 I 1 | 3 I I I 



When the devices in the BCV Table are installed, the BIOS will process the BCV 
Priority shown above in the following order: BCV #1, ATA Drives, Legacy Cards, 
BCV #2. 
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5.4 POST Pseudocode 



The following pseudocode describes an example of managing the BCV Priority during 
POST. 

Created at BIOS build time: 

• First two BCV Table entries are filled in by ATA support and Legacy option ROM 
support. 

• The NV memory space for the IPL Priority is reserved. 
Assumptions: 

• The default for the BCV Priority will automatically be created during POST in case 
the NV memory gets corrupted. 

1 . Call the video option ROM. 

2. Initialize the first two BCV Table entries with ATA Support and Legacy Cards 
respectively. These two entries will always exist in the BCV Table and will always 
be in that order. 

3. Identify all option ROMs with BCVs and add any that are found to the BCV Table. 

4. Call all the BCV option ROMs in the order they reside in the BCV Table and store 
their return value in AX upon return. 

5. If NV memory is corrupted, set defaults for BCV Priority and BCVCount. 

6. Check if the number of BCV devices found this time matches the number found 
last time. If not, update the BCV Priority and BCVCount accordingly. 

7. FOR (i - 0; i < BCVCount + 2; ++i) 

- index = BCV Priority [i]. 

- Call BCVTable.InstallRoutine[index]. 

- There are three possibilities: 

BIOS ATA support: 

- Call installation routine for on-board ATA. 
BCV Device: 

- Set up registers for BCV call. 

- Call the BCV. 
Legacy Cards: 

- Do Legacy ROM scan. 

8. When INT 19h is invoked and INT 13h drive 80h is accessed for booting, the first 
BCV device that installed will respond and boot the O/S. 
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6.0 POST Sequence 



6.1 Power-On Initialization 

6.1.1 Initializing BAIDs 

At some time during POST all BAIDs have to be initialized so that they are ready to 
boot. This would normally include floppy drives and hard drives, but may also 
include any other BAIDs such as CD-ROM, PCMCIA, embedded network adapters, 
etc. Since BAIDs are specific to the BIOS, it is the BIOS' responsibility to initialize 
all BAIDs. 

6.1.2 PnP Boot Devices 

During POST, the PnP BIOS may choose to configure some or all of the devices in the 
system. However, as per the Plug and Play BIOS Specification it is required that a 
PnP BIOS configure all IPL devices including BEVs and BCVs. Any of these devices 
could be on any bus or accessed over a bus bridge, so busses and bridges must be 
enabled as well. All option ROMs must be mapped into system memory between 
COOOOh and EFFFFh. 

6.2 PnP Option ROM Initialization 

It is a requirement for all PnP option ROMs to return control back to the BIOS after 
they have completed their initialization. If a PnP option ROM does not return, it takes 
control away from the BIOS and foregoes compatibility with the BIOS Boot 
Specification. 

First, the video option ROM is called, because it is a special case. Next, only the 
option ROMs containing a valid PnP Expansion Header with either a BEV or a BCV 
are called. The IPL Table and BCV Table are constructed after all option ROMs 
containing a PnP Expansion Header have been called. This allows an option ROM 
that operates under the DDIM (such as PCI) to add PnP Expansion Headers as devices 
are found. See Appendix E for more information on PCI devices with PnP Expansion 
Headers. 

All PnP Cards have their option ROMs initialized by a far call to offset +03h in the 
option ROM header. Option ROMs in PnP Cards will be called in the order of lowest 
to highest with those located at the lowest memory address called first. It is 
recommended that PCI devices store their PFA passed in AX when their option ROM 
is called for initialization. When the far call is made to the PnP option ROM the 
following parameters will be passed: 

ES:DI = Pointer to the PnP Installation Check Structure 

AX = PFA - PCI Bus/Device/Function (PCI devices only) 

BX = Card Select Number (PnP ISA devices only) 

DX = Read Data Port Address (PnP ISA devices only) 
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During this initialization stage, none of the option ROMs called should hook any 
interrupt vectors relating to booting such as INT 9h, lOh, 13h, 18h, or 19h. After 
returning from a PnP option ROM initialization far call, AX will contain status 
information as to the device's booting capabilities. This word is saved for later use 
during the POST process. See the Plug and Play BIOS Specification for the bit 
definitions of AX after the return. 

Option ROMs with a PnP Expansion Header will not be recognized if either one of the 
following is true: 

• It is an option ROM utilizing the Device Driver Initialization Model (DDIM) and 
has re-sized itself to a size of zero. 

• The PnP option ROM returns zero in AX after the initialization call and it has no 
BEV. 

The rest of the PnP option ROMs that have not been called by now are considered to 
be Legacy because they did not contain a PnP Expansion Header. 

6.3 Check IPL Priority and BCV Priority 

This is the stage where the contents of NV storage are checked for corruption. If 
corruption is detected because the check sum failed (or for some other reason), a 
default IPL Priority and BCV Priority that represents the number of devices present 
must be constructed. 

This is also where the number of BEV devices and BCV devices found during POST 
is compared against the number that was found at the last POST. If a change is 
detected, the new number of devices must be stored and the IPL Priority as well as 
BCV Priority must be updated to reflect the addition or loss of devices. 

6.4 INT 13h Device Controller Installation 

When an INT 13h device controller installs its INT 13h support, it typically snoops the 
BDA to detect if any hard drives are currently installed. If so, the controller will make 
its hard drive number one greater than the maximum drive number currently used. For 
example, if two ATA drives are installed (80h and 81h) and a BCV gets called to 
install support for a drive, the BCV will make its INT 13h drive number 82h. This 
precludes it from being an IPL device since only drive 80h is bootable. The result of 
all this is that the first INT 13h device controller that successfully installs will have its 
first drive assigned number 80h and will represent the Hard Drive BAID in the IPL 
Table and IPL Priority. 
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One of the keys to controlling the order of the installation of the INT 13h device 
controllers is selectively calling different option ROMs at specific times. It is critical 
that the BIOS allow the installation of controllers in any order. The three types of 
controllers found in the BCV Table are: those with on-board ATA support; those with 
Legacy option ROMs; and all of the BCV devices that were found. Each of these 
types of controllers has a different method for installing their INT 13h support. The 
ATA support is a call into the BIOS, the Legacy card support is also a call into the 
BIOS that simply calls the remaining option ROMs that don't have the PnP Expansion 
Header, and the BCV devices are controllers that each have a special entry point 
within their PnP option ROM. 

6.4.1 Boot Connection Vectors 

BCV devices are not part of the IPL Priority. The reason for this is twofold. First, 
after a BCV has been called, there is no way to know how many drives it has and if 
any are bootable. Second, whichever drive ends up as INT 13h drive 80h will become 
the BAID for the system's hard drive. 

Each PnP option ROM that contains a BCV will have that vector called. When a BCV 
is called, it allows an option ROM to detect if its device is attached or not and 
conditionally hook INT 13h. If the option ROM decides not to install its support, it 
should not hook INT 13h, but it should perform any clean-up before returning to the 
BIOS. For instance, the BDA should remain unmodified if the device did not install. 

A device's BCV in the PnP Expansion Header is valid if it is not zero and the BEV is 
zero, since these two vectors are mutually exclusive. When the BIOS makes a far call 
to the BCV the following parameters are passed: 

ES:DI = Pointer to PnP Installation Check Structure 

AX = Flags for interrupt(s) that may be hooked (PnP ISA 

devices only) 

BX = Card Select Number (PnP ISA devices only) 

DX = Read Data Port Address (PnP ISA devices only) 

Note that for PCI cards, AX will not contain the PFA. PCI devices that need their PFA 
during execution of their BCV should store the PFA passed earlier when their option 
ROM's initialization vector was called. 
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6.4.2 Disconnect Vector 

Originally, it was thought that the DV would be called by the BIOS if the device's 
BCV was called and subsequent booting from the device failed. However, it was later 
discovered that current PnP option ROMs are more well behaved by checking during 
the BCV call if their device will properly respond to INT 13h calls or not, and simply 
not hooking INT 13h if those calls would fail. Because of this, the DV is not called by 
a BIOS supporting the BIOS Boot Specification, nor is it necessary to have a valid DV 
in the PnP Expansion Header. The DV should be NULL and can't be used for other 
storage. 

6.4.3 Legacy ROM Scan 

A scan for Legacy option ROMs in system memory from COOOOh to EFFFFh on 2k 
boundaries is performed in the order of lowest to highest. Any option ROM with a 
PnP Expansion Header is ignored. When an option ROM is found its initialization 
vector is executed by a far call to offset +03h in the option ROM header. The contents 
of CPU registers passed to and returned from the option ROM call are ignored with the 
exception of PCI option ROMs. PCI option ROMs will be called with the PFA in the 
AX register as per the PCI Specification. 

6.4.4 On-board ATA Support 

The installation of the BIOS' own ATA drive support into the INT 13h services should 
be performed in the same way that BCV devices install their support, by recognizing 
the drives already installed and adding on drive numbers above those previously 
installed. 

For example, if the BCV priority was set to the following: [BCV device #1, ATA 
support, Legacy cards, BCV device #2], and if a BCV was the first INT 13h device 
controller to install and hook into INT 13h to add support for a drive, it would occupy 
drive 80h. Then when the BIOS installs its support for an ATA drive, it should occupy 
drive 81h. 

6.5 INT 19h Processing 

By the time INT 19h gets invoked, all types of IPL devices have been identified and 
initialized, all INT 13h device controllers have installed, and the IPL Table contains 
references to all the available IPL devices. The first INT 13h device controller that 
installed successfully will occupy drive 80h and will be represented by the Hard Drive 
B AID in the IPL Table. 
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All that is left is to sequentially go through the IPL Priority, use each ordinal value as 
an index into an entry in the IPL Table, and attempt to boot from that device. Each 
entry in the IPL Table contains a pointer to a procedure that will attempt booting. The 
BIOS calls this boot handler address. The first IPL device that succeeds will load the 
O/S. If IPL an device fails to boot, the BIOS regains control and selects the next IPL 
device in the IPL Priority. This process continues until all IPL devices have failed. If 
all IPL devices fail to boot an error message is displayed and the booting process starts 
over again. 

Implementation Specific Note: 

It may be useful for the items in the IPL Table to be displayed to the user at the end of 
the INT 19h handler if all devices have failed to boot an O/S. This way the user can 
attempt to rectify the situation. Alternately, the user could be prompted to enter Setup 
if it were accessible at that time. 
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6.5.1 Booting from BAIDs 

The BIOS attempts to boot from a BAID by calling a boot handler address that is 
located within the BIOS. The responsibility of loading the boot sector from the device 
and transferring control to it falls on the boot handler procedure. If the device fails to 
boot, it should invoke INT 1 8h, since this is now the boot recovery vector. 

When the boot handler is called, the BIOS passes a pointer to the PnP Installation 
Check Structure in ES:DI. This is so that once the boot handler has successfully 
loaded the device's boot sector into memory at address 0000:7C00h 3 execution control 
can be transferred with the following register contents: 

ES:DI = Pointer to PnP Installation Check Structure 

DL = Drive number used for the INT 1 3h (OOh, 80h, etc.) 

6.5.2 Booting from BEVs 

The BEV, which is found in the PnP Expansion Header, is for devices which do not 
have INT 13h support routines in their option ROMs and require their own proprietary 
method to load the O/S. Devices utilizing the BEV method are typically remote 
program load devices such as network cards. 

The BEV device can be thought of as a generic way to boot from any type of device 
and allows for the future definition of other IPL devices. A PnP Card's BEV is valid if 
it is not zero and the BCV is zero, since these two vectors are mutually exclusive. 

If a BEV device is selected for booting, its BEV will be called from within the INT 
19h handler. The device will then attempt to load boot code into memory and execute 
the O/S. If the O/S load fails, the device must clean up any memory areas it modified 
and then invoke INT 18h to allow control to return to the system BIOS. Specifically, 
data areas such as the interrupt vector table, the BDA, and the Extended BIOS Data 
Area must remain unchanged. 
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6.6 INT 19h Pseudocode 



The following pseudocode describes an implementation of the INT 19h process. 
Assumptions: 

• Maximum number of supported BAIDs and BEV devices = 8, indexed as 0..7 in 
the IPL Priority. 

Execution at INT 19h time: 

• IPLcount = current number of BAIDs and BEV devices at this boot. 

• FOR (i = 0; i < IPLcount; ++i) 

• currentIPL = IPL Priority[i]. 

• Use currentIPL to index the IPL Table entry. 

• Do a far call to the entry's boot handler or BEV, if successful we never 
return. 

• IF (control returns via RETF, or an INT 1 8h) 

• Clean up the stack if necessary. 

• ENDIF 

• Execute an INT 1 8h instruction. 

6.7 INT 18h Pseudocode 

The original INT 18h handler jumped into a ROM-based BASIC interpreter. On 
compatible PCs, INT 18h typically displays an error message, waits for a key stroke, 
and then executes an IRET instruction. The BIOS Boot Specification redefines INT 
18h as the recovery vector for failed boot attempts. The following pseudocode 
describes an implementation of the INT 18h process. Note that INT 18h does not, and 
cannot return to its caller because the stack has been reset. 

Execution at INT 18h time: 

• Reset stack. 

• IF (all IPL devices have been attempted) 

• Print an error message that no O/S was found. 

• Wait for a key stroke. 

• Execute the INT 19h instruction. 

• ELSE 

• Determine which IPL device failed to boot. 

• Jump to a label in the INT 19h handler to try the next IPL device. 

• ENDIF 
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6.8 Notes on the POST Process 

• The Plug and Play BIOS Specification says that if a Legacy IPL device's option 
ROM captures INT 18h or INT 19h, the BIOS should save this vector and then 
restore the original one put there by the BIOS. The BIOS Boot Specification 
deviates from this in that these vectors are not recaptured after each Legacy option 
ROM returns from initialization. That would be considered unsafe. 

• If the system attempts to boot from a formatted non-bootable (data) floppy 
diskette, the INT 13h reads will be successful and control will be transferred to the 
resident boot sector on the diskette after it is loaded into memory. However, this 
boot sector code will determine that this diskette doesn't contain an O/S and it 
eventually may issue an INT 19h to attempt to start the booting process over. This 
could result in the INT 1 9h handler being executed all over again, thus creating an 
infinite loop. 

• If the system attempts to boot from a non-bootable formatted (data) hard drive, 
when its boot sector is loaded and starts executing, it discovers that an O/S is not 
present. This code may issue an INT 18h. The INT 18h instruction is issued 
instead of INT 19h because the hard drive boot sector assumes that the floppy 
drive has already attempted to boot and failed. This behavior is left over from the 
IBM AT. 

• If a Legacy IPL device fails to boot it may do one of several things: 

1. It may display an error message and never return control to the BIOS, thus 
hanging the system. 

2. If the device trapped INT 13h, it may invoke INT 19h or INT 18h to 
attempt to allow the BIOS to select another device to boot. 

3. If the device trapped INT 19h, it may invoke INT 18h. 

• There is currently no defined standard for the usage of conventional memory by 
option ROMs during POST. However, it's recommended that options ROMs 
needing temporary storage when their initialization vector is called use RAM in the 
first 64k segment that is not currently defined for other purposes. Specifically, the 
memory range from address 0000:7C00h to 0000:FFFFh can be used, provided the 
stack is not located in this area. 
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Appendix A: Data Structures 
A.1 IPL Table and BCV Table Entry Data Structure 





wmm 






deviceType 


00h 


WORD 


See definitions below. 


statusFlags 


02h 


WORD 


See bit definitions below. 


bootHandler 


04h 


FAR PTR 


Far pointer to address of boot handler. 


descString 


08h 


FAR PTR 


Far pointer to ASC1IZ description string. 


expansion 


OCh 


DWORD 


Reserved for future expansion. 



Both the IPL 
contiguously. 
deviceType: 



statusFlags: 
bootHandler 



descString: 
expansion: 



Table and the BCV Table consist of one or more of the above data structures arranged 
The same data structure is used for both IPL Table and BCV Table entries. 

An identification number that describes what type of device this is. 

OOh = Reserved 

01h = Floppy 

02h = Hard disk 

03h = CD-ROM 

04h = PCMCIA 

05h = USB device 

06h = Embedded network 

07h..7Fh = Reserved 

80h = BEV device 

81h..FEh = Reserved 

FFh = Unknown 

See table of bit definitions below. 

For IPL devices, this points to a procedure that will attempt to load an O/S from this 
device. For BCV devices, this points to a procedure that will allow the device to 
attempt to install into INT 13h services. 

This points to an ASCIIZ string that describes this device to a user. 
Reserved for future definition. Must be zero. 



Bit definitions of the statusFlags field: 





;M* Field 


flValue 


Description 


3..0 


Old Position 


0..15 


This entry's index in the table at the last boot. For updating the 
IPL or BCV Priority if individual device detection is done. 


7. A 


(Reserved) 


0 


Reserved for future use, must be zero. 


8 


Enabled 


0..1 


0 = Entry will be ignored for booting (IPL); entry will not be 
called for boot connection (BCV). 

1 = Entry will be attempted for booting (IPL); entry will be called 
for boot connection (BCV). 


9 


Failed 


0..1 


0 = Has not been attempted for boot, or it is unknown if boot 
failure occurred (IPL); entry connected successfully (BCV). 

1 = Failed boot attempt (IPL); failed connection attempt (BCV). 


11..1 
0 


Media Present 


0..3 


0 = No bootable media present in the device. 

1 = Unknown if bootable media present. 

2 = Media present and appears bootable. 

3 = Reserved for future use. 


15..1 
2 


(Reserved) 


0 


Reserved for future use, must be zero. 
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A.2 PnP Option ROM Header 







iEKalueflll 




00h 


BYTE 


55h 


Signature byte 1 . 


Olh 


BYTE 


AAh 


Signature byte 2. 


02h 


BYTE 


Varies 


Option ROM length in 512-byte blocks. 


03h 


4 BYTES 


Varies 


Initialization entry point. 


07h 


17 BYTES 


Varies 


Reserved. 


18h 


WORD 


Varies 


Offset to PCI data structure. 


lAh 


WORD 


Varies 


Offset to expansion header structure. 



A. 3 PnP Expansion Header 









D^criTtibTT * T*WW 


OOh 


BYTE 




Signature byte 1 . 


Olh 


BYTE 


'P' 


Signature byte 2. 


02h 


BYTE 


'n' 


Signature byte 3. 


03h 


BYTE 


'P' 


Signature byte 4. 


04h 


BYTE 


Olh 


Structure revision. 


05h 


BYTE 


Varies 


Length (in 16 byte increments). 


06h 


WORD 


Varies 


Offset of next header (OOOOh if none). 


08h 


BYTE 


OOh 


Reserved. 


09h 


BYTE 


Varies 


Checksum. 


OAh 


DWORD 


Varies 


Device identifier. 


OEh 


WORD 


Varies 


Pointer to manufacturer string (Optional). 


lOh 


WORD 


Varies 


Pointer to product name string (Optional). 


12h 


3 BYTES 


Varies 


Device type code. 


15h 


BYTE 


Varies 


Device indicators. 


16h 


WORD 


Varies 


Boot Connection Vector (BCV), OOOOh if none. 


18h 


WORD 


Varies 


Disconnect Vector (DV), OOOOh if none. 


lAh 


WORD 


Varies 


Bootstrap Entry Vector (BEV), OOOOh if none. 


ICh 


WORD 


OOOOh 


Reserved. 


lEh 


WORD 


Varies 


Static resource information vector (OOOOh if none). 
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wrnmm 
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OOh 


BYTE 




Signature byte 1 . 


Olh 


BYTE 


'C 


Signature byte 2. 


02h 


BYTE 


T 


Signature byte 3. 


03h 


BYTE 


'R' 


Signature byte 4. 


04h 


WORD 


Varies 


Vendor Identification. 


06h 


WORD 


Varies 


Device Identification. 


08h 


WORD 


Varies 


Pointer to Vital Product Data. 


OAh 


WORD 


Varies 


PCI Data Structure Length. 


OCh 


BYTE 


Varies 


PCI Data Structure Revision. 


ODh 


3 BYTES 


Varies 


Class Code. 


lOh 


WORD 


Varies 


Image Length. 


12h 


WORD 


Varies 


Revision Level of Code/Data. 


14h 


BYTE 


Varies 


Code Type. 


15h 


BYTE 


Varies 


Indicator. 


16h 


WORD 




Reserved. 
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Appendix B: Run-Time Functions (Optional) 



It may be desirable for an 0/S or application program to access the features of the 
BIOS Boot Specification during run-time. An application may want to query the 
number and type of IPL devices in the system, display an IPL device menu and allow 
the user to organize the IPL devices, or specify that the BIOS should attempt booting 
from a particular device on the next system restart. 

What follows is a set of extensions to the Plug and Play run-time functions that 
implement the BIOS Boot Specification run-time services. Functions 60h through 6Fh 
are henceforth reserved for the BIOS Boot Specification. Refer to the Plug and Play 
BIOS Specification for the details of the calling conventions. 

Run-Time Function Restrictions: 

1. This API is specific to the data structures defined in Appendix A. 

2. Any device that has a corresponding entry in the IPL Table or BCV Table cannot 
have its option ROM removed from memory. 

3. In an implementation of this API, all defined data structures and fields must be 
valid. 

4. If function 60h returns SUCCESS, then functions 61h, 62h, 63h, and 64h must be 
implemented. This is because function 60h is used by the caller to effectively test 
for the presence of the other functions. 

5. Both functions 65h and 66h are optional, since they are specific to the Boot Menu 
feature described in Appendix C. However, they are a matched pair such that if one 
function is implemented, the other function must be implemented as well. 

6. All functions are available in Real Mode and 16:16 Protected Mode. 
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Function 60h - Get Version and Installation Check 

Synopsis: 

short FAR (* entryPoint) (Function, Version, B ios Selector) ; 
short Function; // PnP BIOS function 60h. 

unsigned short FAR * Vers ion; // Version of BIOS Boot Specification returned, 
unsigned short BiosSelector; // PnP BIOS readable/writable selector. 
Description: 

This function is used to check for the presence of a BIOS that is compliant with the 
BIOS Boot Specification and return the version number. This function is available in 
Real Mode and 16-bit Protected Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 

Version. Contains the version number in binary coded decimal (BCD) format. For 
example, if BX returns with OlOlh, the version is 1.01. The major version is 
incremented when this API changes. The minor version is incremented when 
underlying functionality changes and this API remains the same. 
BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 16-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification. 



35 



Function 61 h - Get Device Count 

Synopsis: 

short FAR (* entryPoint) (Function, Switch, Count, MaxCount, StructSize, 
BiosSelector); 

short Function; // PnP BIOS function 61 h 

short Switch; // 0 = IPL relative, I = BCV relative, 

unsigned short FAR *Count; //Number of devices in the system, 
unsigned short FAR * MaxCount; //Maximum number of devices supported, 
unsigned short FAR *StructSize; //Size of a Table entry in bytes, 
unsigned short BiosSelector; // PnP BIOS readable/writable selector. 
Description: 

This function is used to return the number of IPL or BCV devices currently present, 
the maximum number of IPL or BCV devices supported, and the size of an IPL or 
BCV Table entry. This function is available in Real Mode and 16-bit Protected Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 

Switch. Flag for whether the function refers to the IPL Table or BCV Table. 
Count Contains the number of IPL or BCV devices present 
MaxCount. Specifies the maximum number of IPL or BCV devices supported. 
StructSize. Designates the size of an IPL or BCV Table entry in bytes. 
See appendix A for the structure of an IPL or BCV Table entry. 
BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 1 6-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification. 
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Function 62h - Get Priority and Table 

Synopsis: 

short FAR (* entryPoint) (Function, Switch, Priority, Table, B iosSe lector) ; 



//PnP BIOS function 62 h. 

//0 = IPL relative, 1 = BCV relative. 

// Copy of Priority in NV memory returned. 

// Copy of Table. 

//PnP BIOS readable/writable selector. 



short Function; 
short Switch; 

unsigned char FAR * Priority; 
unsigned char FAR *Table; 
unsigned short BiosSelector; 
Description: 

Function 61h Get Device Count must be called prior to calling this function so that 
the proper memory buffers can be allocated by the caller. 

This. function is used to copy the IPL or BCV Priority and IPL or BCV Table into the 
caller's destination buffers. This function is available in Real Mode and 16-bit 
Protected Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 

Switch. Flag for whether the function refers to the IPL Table or BCV Table. 
Priority. A byte array of size maxCount, the maximum number of IPL or BCV 
devices supported in the system. Only the first Count bytes in the IPL or BCV 
Priority are valid. 

Table. An array of IPL Table or BCV Table entries containing information about 
each IPL or BCV device. The number of IPL or BCV Table entries is equal to 
maxCount. The size of the Table buffer is equal to {maxCount * StructSize) bytes. 
The caller must allocate enough memory for the destination buffers. 
BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 1 6-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification. 
Example of Boot Priority and IPL Table: 

In a system where maxCount = 8, Count - 3; where there are two BAIDs, one BEV 
device; and the IPL Priority = 02h, Olh, OOh representing a boot order of network 
card, first hard drive, first floppy drive; Priority would point to a buffer containing the 
following: 



rp2h 



Olh OOh 



IPL Priority. 



and Table would point to a buffer containing the following: 



Olh 


OOh 


23h 


Elh 


OOh 


FOh 


45h 


E3h 


OOh 


FOh 


first BAID, first floppy 
drive 


02h 


OOh 


45h 


E2h 


OOh 


FOh 


60h 


E3h 


OOh 


FOh 


second BAID, first hard 
drive 


80h 


OOh 


EOh 


OEh 


OOh 


C8h 


48h 


OOh 


OOh 


D4h 


first BEV, PnP ethernet 
card 
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Function 63h - Set Priority 

Synopsis: 

short FAR (* en try Point) (Function, Switch, Priority, B ios Selector); 
short Function; // PnP BIOS function 63 h. 

short Switch; //0 = IPL relative, I = BCV relative, 

unsigned byte FAR * Priority; //Priority to write to NV memory, 
unsigned short BiosSelector; // PnP BIOS readable/writable selector. 
Description: 

Function 62h Get Priority and Table must be called prior to calling this function so 
that the original Priority has been obtained. The contents of Priority are justified 
toward the beginning. The entries in Priority may be moved from one location to 
another, but it is required that no new values are written into Priority. This function 
is used to write an IPL or BCV Priority into NV RAM. This function is available in 
Real Mode and 16-bit Protected Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 

Switch. Flag for whether the function refers to the IPL Table or BCV Table. 
Priority. A byte array of size maxCount, the maximum number of devices supported 
in the system. Only the first Count bytes in Priority are written into NV RAM. 
BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 16-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification. 
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Function 64 h - Get IPL Device from Last Boot 

Synopsis: 

short FAR (* entryPoint) (Function, IPLEntry, BiosSelector); 
short Function; // PnP BIOS function 64h. 

unsigned short FAR VPLEntry; //Index of entry in IPL Table, 
unsigned short BiosSelector; // PnP BIOS readable/writable selector. 
Description: 

This function is used to find out which device in the IPL Table was used on the last 
O/S boot. This function is available in Real Mode and 16-bit Protected Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 
IPLEntry. Contains an index of an entry in the IPL Table. 

BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 16-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification, 
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Function 65h - Get Boot First 

Synopsis: 

short FAR (* entryPoint) (Function, IPLEntry, BiosSelector); 
short Function; // PnP BIOS function 65 h. 

unsigned short FAR VPLEntry; //Index of entry in IPL Table, 
unsigned short BiosSelector; // PnP BIOS readable/writable selector. 
Description: 

This function is used to find out which device in the IPL Table is currently selected as 
the Boot First device. This function is available in Real Mode and 16-bit Protected 
Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 

IPLEntry. Contains an index of an entry in the IPL Table currently selected as the 
Boot First device. Valid values are OOh through FEh. A value of FFh means that 
there is currently no Boot First device selected. 

BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 16-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification. 
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Function 66h - Set Boot First 

Synopsis: 

short FAR (* entry Point) (Function, IPLEntry, BiosSelector) ; 
short Function; // PnP BIOS function 66h. 

unsigned short FAR *IPLEntry; //Index of entry in IPL Table, 
unsigned short BiosSelector; // PnP BIOS readable/writable selector. 
Description: 

This function is used to set the Boot First device. The Boot First device is used to 
boot from first before the IPL Priority is considered. This function is available in Real 
Mode and 16-bit Protected Mode. 
Parameters: 

Function. Plug and Play BIOS function number. 

IPLEntry. Contains an index of an entry in the IPL Table to be the new Boot First 
device. 

BiosSelector. This parameter enables the system BIOS, if necessary, to update the 
system variables that are contained in the system BIOS memory space. If this 
function is called from Protected Mode, the caller must create a data segment 
descriptor using the 16-bit Protected Mode data segment base address specified in the 
Plug and Play Installation Check Structure, a limit of 64KB, and the descriptor must 
be read/write capable. If this function is called from Read Mode, BiosSelector should 
be set to the Real Mode 16-bit data segment address as specified in the Plug and Play 
Installation Check Structure. 
Returns: 

0 if successful - SUCCESS. 

!0 if an error (Bit 7 set) or a warning occurred or no pending events - error code. The 
function return codes are described in Appendix C of the PnP BIOS Specification. 
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Appendix C: Boot Menu (Optional) 



C.1 Boot Menu Pop-up 

Another way to view the IPL Priority is to use a Boot Menu that pops up during 
POST. If you press <Hot-Key> during POST, the Boot Menu will appear just before 
the BIOS issues INT 19h. The Boot Menu won't appear unless <Hot-Key> is pressed 
As in Setup, the Boot Menu displays all the IPL devices in the order they will be 
selected for booting. However, unlike in Setup, the Boot Menu doesn't allow you to 
edit the position of an IPL device in the IPL Priority. This menu simply allows you to 
select a Boot First device. A Boot First device attempts bootingfirst before the regular 
IPL Priority is considered. You select a Boot First device from the Boot Menu by 
using the up/down arrow keys to move the highlight bar to the desired device, and then 
by pressing <Enter> the ordinal value from the IPL Priority for this selection is stored 
so that later the INT 19h handler can boot from this device. If you press <Hot-Key> 
while the Boot Menu is up, the Boot Menu exits without saving a selection. 

The key defined as <Hot-Key> is dependent upon the particular implementation. For 
example, the <Esc> key could be used. 

C.2 Boot Menu INT 19h Pseudocode 

When the BIOS' INT 19h handler gets control, it checks to see if a Boot Menu IPL 
device was selected for booting. The following pseudocode is done before the normal 
INT 1 9h processing, which works only from the IPL Priority. 

• IF (A Boot Menu selection was made) 

• currentIPL = IPL Priority [Boot Menu selection]. 

• Use currentIPL to select the BAID or BEV table entry. 

• Do a far call to the boot handler, if successful we never return. 

• IF (we get control back via RETF, or an INT 18h): 

• Clean up the stack if necessary. 

• END IF 

• ENDIF 

C.3 Boot First Run-Time Functions 

If it is necessary to duplicate the Boot Menu functionality in software, then getting and 
setting the Boot First device could be accomplished by run-time functions instead of 
requiring the user to access a Boot Menu. The run-time functions 65h and 66h could 
be used by an O/S or application program to get and set the Boot First selection. 
These functions are not required in an implementation of the Boot Menu feature. 
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Appendix D: Recommended Boot Sector Changes (Optional) 



If O/S's responded to the mechanism of passing the INT 13h drive number to the boot 
sector as defined by the Plug and Play BIOS Specification, the BIOS could boot from 
any INT 13h drive. Also, if a standard method of returning control to the BIOS upon 
boot failure were established, the BIOS could try to boot from the next device. Here 
are two recommended changes to the O/S boot sector code in order to enhance the 
booting capabilities of the BIOS. 

D.1 Use DL for Drive Number 

Use the drive number passed in the DL register by the BIOS when control is 
transferred to the boot sector for INT 13h accesses to load the O/S, instead of having 
the drive number hard-coded. This would allow booting from drives other than just 
OOh (A:) and 80h (C:). 

D.2 INT 18h on Boot Failure 

If an O/S is either not present, or otherwise not able to load, execute an INT 18h 
instruction so that control can be returned to the BIOS. Currently, hard drive boot 
sectors do this, but floppy diskette boot sectors execute an INT 19h instead of INT 
18h. The BIOS Boot Specification defines INT 18h as the recovery vector for failed 
boot attempts. 

Both of these solutions should be backward compatible with previous BIOS and O/S 
versions. 
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Appendix E: PCI with Multiple PnP Headers (Optional) 



E.1 Description 

The following procedure describes a method by which the option ROM on a PCI SCSI 
controller can allow a PC system BIOS to selectively recognize and install individual 
SCSI drives into the BIOS' INT 13h services. This is presented as an example of the 
more general case where a PCI option ROM with a PnP Expansion Header can 
implement multiple headers to allow recognition of individual devices. 

The procedures described below allow the user to control the order in which individual 
drives are installed into the BIOS' INT 13h services. This has two major benefits. 
First, the order the drives appear in the INT 1 3h services controls the assignment of 
drive letters under the DOS and Windows environments. Although drives with 
multiple partitions can defeat this feature, in the worst case it still offers the user some 
control. Second, the first device to successfully install into INT 13h services will 
assign itself drive number 80h. Because of current operating system boot sector 
limitations, this is the only drive number that can be a boot device. Thus the user is 
selecting their boot device from any number of possibilities. 

E.2 Requirements 

• The computer must have a PCI bus, and the system BIOS must provide both PCI 
and Plug and Play support. 

• The SCSI controller must be PCI and expect its option ROM to be shadowed. 

• The system BIOS must support boot device control as defined earlier in the BIOS 
Boot Specification. 

E.3 Option ROM Initialization 

E.3.1 Before Option ROM Placement 

One PnP Expansion Header structure exists in the PCI SCSI option ROM in the 
original binary image before the BIOS performs placement. The Boot Connection 
Vector (BCV) within this single header should be valid. At this point the header itself 
is merely for identification purposes so that the BIOS can enumerate all such devices 
in the system. 

E.3. 2 Placing the PCI Option ROM 

The location of the option ROM in upper memory is chosen by the system BIOS. The 
segment address of the option ROM is determined by the value in the CS register 
when the ROM's initialization code gains control. The option ROM is shadowed into 
an available location within physical memory addresses COOOh-EFCOh on a 2k 
boundary. 
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E.3.3 Calling the PCI Option ROM 

It is guaranteed that all option ROMs will be called to initialize before the BIOS scans 
memory for option ROMs containing PnP Expansion Headers and builds the IPL and 
BCV Tables. This allows PnP Expansion Headers to be added and removed during 
their option ROM initialization without confusing the BIOS. 

The option ROM has been shadowed and is write-enabled. 

The CPU registers are set up as follows: 
AX PFA for this PCI adapter. 
CS Segment address of option ROM. 

ES:DI Far pointer to the $PnP Installation Check Structure in the system BIOS. 

At this time, the option ROM performs any necessary initialization and determines the 
number of devices it will control. The option ROM may also determine if another 
adapter in the system has already installed and taken over its devices. 

E.3.4 No Devices Present 

If no devices are present, the option ROM should return to the BIOS without 
modifying the system interrupt vectors or other data areas. The return value in AX 
would be OlOOh. This indicates that, although the adapter supports the INT 13h block 
device format, it failed to install properly because it had no devices attached. 

E.3.5 Devices are Present 

If one or more devices are present, the option ROM creates additional PnP Expansion 
Headers, one for each device found, in a linked list to the first one. Each header, 
including the first header, then represents an individual device. For example, if two 
SCSI drives are attached, header 1 (pointed to by offset 1 Ah in the option ROM) 
represents the first drive (SCSI id 0), and the 'Offset of Next Header' field within 
header 1 is a link to header 2. Header 2 then represents the second SCSI drive (SCSI id 
1) attached to the adapter. This can continue up to the maximum number of SCSI 
devices supported on that adapter. This linked list of headers terminates when a 
header's 'Offset of Next Header' field is zero. 

The data within each header must be valid. Especially the 'BCV and 'Pointer to 
Product Name String' fields. The BCV should point to a procedure that installs only 
that device into INT 13h services. It is strongly recommended that the Product Name 
String for each header uniquely identify the device to which that header belongs, so 
that when these strings are displayed to the user in a menu, the user can intelligently 
recognize and choose devices connected to that controller without having to open up 
the computer. 

Multiple SCSI adapters can be accommodated by one SCSI option ROM using the 
scheme described above. It is only important that each header correspond to an 
individual device. For example, if two PCI SCSI adapter cards are present in a system, 
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the option ROM for the first one called by the system BIOS could enumerate all the 
devices present on both adapters and create a linked list of PnP Expansion Headers 
covering all these devices accordingly. When the second adapter's option ROM is 
called by the system BIOS, it would determine that the first adapter is already present 
and controlling the second adapter's devices. The second adapter would then minimize 
the size of its option ROM to free UMB space, zero out the BCV within its PnP 
Expansion Header (so it won't be called), and then return to the system BIOS with AX 
containing OlOOh indicating no devices were found. 

E.4 Enumerating PnP Expansion Headers 

Once all option ROMs with PnP Expansion Headers have been initialized, the BIOS 
will scan memory again and build a table of all the PnP Expansion Headers that are 
found so that the user can order these devices on a menu in Setup. The system BIOS 
will manage changes as devices are inserted and removed from the system as 
described earlier. 

E.5 Calling the BCVs 

The BIOS maintains the order in which the PnP Expansion Headers are called for 
installation. The calling of BCVs is driven from this order. Please refer to section 5.2.5 
Controller Installation Guidelines for details on the expected behavior of the option 
ROM when its BCV is called. Essentially, each BCV procedure will install only its 
corresponding device into INT 13h services. 

As outlined earlier, the system BIOS controls the installation order of all types of INT 
13h devices via the BCV Table and BCV Priority. This includes ATA (IDE) drives, 
PnP BCVs, and a ROM scan for Legacy and non-PnP PCI cards. 
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